home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15494 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.1 KB
  1. Path: snews.tcel.com!netway
  2. From: tech@netway.ab.ca (Ritchie Annand)
  3. Newsgroups: comp.lang.c++,comp.lang.pascal,comp.lang.pascal.borland,comp.lang.pascal.delphi.misc,comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.tools,comp.os.ms-windows.programmer.tools.misc,comp.windows.ms.programmer
  4. Subject: Re: HELP: C++ or DELPHI ? We need translate DOS program which written in BP/TV.
  5. Date: 6 Apr 1996 09:57:23 GMT
  6. Organization: Telnet Canada (403) 262-5859 info@tcel.com
  7. Message-ID: <4k5f63$e9k@challenge.tcel.com>
  8. References: <DoJ6yG.FIn@actcom.co.il> <315C20CD.7CEE@airmail.net>
  9. NNTP-Posting-Host: 204.209.150.60
  10. X-Newsreader: News Xpress Version 1.0 Beta #4
  11.  
  12. In article <316166F5.6972@airmail.net>, Brian Ebarb <ebarb@airmail.net> 
  13. wrote:
  14. >I see a striking parallel here between this subject and the early days of 
  15. >Mac development.  The Mac operating system was written in Pascal, and when 
  16. >the first Mac programming interface was provided via the Apple Lisa, the 
  17. >native tongue was Pascal. When 'Inside Macintosh' was FINALLY published a 
  18. >couple of years later (when Mac-based development tools were finally 
  19. >available), Pascal was still the native language. At that time, developers 
  20. >argued that writing Mac applications in anything but Pascal would lead to 
  21. >trouble, and at that time I generally agreed.
  22.  
  23. The major sticky points were probably on calling convention and native string 
  24. formats - that's the sort of thing we still see some qualms about today, but 
  25. at least vendors can handle this now.
  26.  
  27. >The native tongue of Windows development is C/C++. Microsoft has worked hard 
  28. >to provide the VBA interface to 32-bit Windows mechanisms such as OLE, etc., 
  29. >which allows VB to hook into some serious areas of the OS. I assume that 
  30. >Delphi is a C->Pascal port in much the same way that Lisa Pascal was ported 
  31. >to C in the early Mac C environments (such as Aztec, MetaWare, etc.) SO -- 
  32. >Delphi is probably capable of generating more powerful apps than Visual 
  33. >Basic. 
  34.  
  35. They went off and created their *own* calling convention, though (stdcall).  
  36. Sometimes I get the impression they make updates to their OS with almost the 
  37. express intent of breaking other peoples' tools (variants, anyone?).
  38.  
  39. Delphi's a successor to Borland's Turbo Pascal series (1.0-7.0.  It was going 
  40. to be called Borland Pascal 8.0 at the onset) which has been around for quite 
  41. some time - with Anders H. at the helm.  Borland has also worked hard at 
  42. providing the Delphi interface to Windows 32-bit mechanisms (OLE, automation, 
  43. native variant types, direct access to API, etc.)
  44.  
  45. >The apps I'm involved with are just too large and complex to be written in 
  46. >VB. An endorsement for Delphi from the VB community doesn't change my 
  47. >technical requirements of a development environment. Since I have to use 
  48. >C/C++ for my large apps, I wouldn't consider diluting my skills by using 
  49. >another development environment for smaller projects. SO -- if a programmer 
  50. >knows that he/she'll never get involved in a project that's just too large 
  51. >for Delphi, and doesn't already have a solid base in the C/C++ based tools, 
  52. >go for it.
  53.  
  54. <grin> Ah!  You want to see an endorsement from the "rougher edge".  I've 
  55. worked with BC++ 4.0 and extensively with VACPP 3.0, and there is comparable 
  56. ability to handle large projects with Delphi.  Delphi's steeped in OOP, and 
  57. while those who prefer "not to get their hands dirty" who wire their user 
  58. interface to itself and to a database layer by simple component use may do 
  59. so, anyone working on a project of any reasonable size is at liberty to found 
  60. their project in the Model/Control/Business Objects realm and model their 
  61. objects and domains appropriately.  One of our user group members gave a good 
  62. presentation to the rest of the users on this subject.
  63.  
  64. Techniques for going about this are quite similar to those in C++, and OO 
  65. tools of the likes of Rational Rose are poised to come onto the market soon 
  66. (which is good news for those who dislike writing code skeletons ;)
  67.  
  68. >Remember tho - Powersoft sold PowerBuilder as a tool that could not be 
  69. >outgrown, alleging that it was scalable and could handle anything. This has 
  70. >proven to be woefully wrong, and jobs have been lost or jeopardized over the 
  71. >fiascos that belief in Powersoft's claims have wrought. With this in mind, 
  72. >is it then reasonable to carry blind faith in yet another non-native 
  73. >vendor's promises? It would make me too nervous.
  74.  
  75. PowerBuilder is a tool along the lines and power of Visual Basic, though a 
  76. bit slower on the execution side (!), and, if I recall rightly, is not OO, 
  77. but rather object-based like VB, and database access was two-tiered instead 
  78. of three-tiered like Delphi, making some changes horrible to contemplate.  
  79. Still, they are giving the field another go with their C++-based Optima++ 
  80. (with DataWindow class ;)
  81.  
  82. >THAT'S what I meant by 'go with the power'. I am comfortable in the 
  83. >knowledge that no matter where Microsoft leads Windows 16 or 32, I'll be 
  84. >able to write apps that are as large as the OS can handle, not just as large 
  85. >as the development tool can handle.
  86.  
  87. Well, they've got to have *something* to test out their new OS features, 
  88. don't they ;)
  89.  
  90. >Gnarly, dude.
  91.  
  92. Be excellent to somebody ;)
  93.  
  94.   --=- Ritchie A.
  95.